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Dynamic Dispatch Function 



The present invention relates to a method for enabling a first software program 
using a first binary specification to employ a limited functionality of a second 
software program using a second binary specification. 

Many software programs, which are created in different programming languages, 
have to communicate with each other. For example, a first software program cre- 
ated in a first programming language is able to provide tables. It calls another 
software program created in a second programming language which is able to 
calculate figures which are needed in the table to be produced by the first pro- 
gram. The calculation program cannot be called by the table program, since these 
two programs use different binary specifications for the communication because 
of their different programming languages. In the context of the present invention 
the different binary specification can be caused by different programming lan- 
guages as well as by different compilers for the same programming language, 
since the communication problems caused by a different programming language 
and by different compilers for the same programming language are comparable, if 
not identical. 

The prior art solution to this problem is to provide transformer modules for each 
required transformation route, for example from a certain first binary specification 
to a certain second binary specification. Since in modern computer applications 
many different software programs may be called by a certain software program, 
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the computer system requires a voluminous library of transformer modules. This 
extensive library needs significant storage space and regular maintenance, since 
for every new binary specification which shall be accessible a full new set of 
transformer modules must be provided, in addition to the existing transformer 
modules. However, most of these transformer modules are not used frequently, so 
that their storage is not efficient. 

Furthermore, these prior art transformer modules extend to the full functionality 
of the software program to be translated from one binary specification to another. 
Due to the regularly wide functionality of software programs known transformer 
modules are rather voluminous and require, when they are activated, a significant 
amount of working memory and processor time from the computer system on 
which they are carried out. Furthermore, the complete translation of a software 
program is burdensome and time consuming, although it is in most cases unneces- 
15 sary for the specific task to be accomplished. 

Therefore, it is an object of the present invention to provide an efficient method to 
enable a first software program to employ certain functionalities of a second soft- 
ware program, wherein the first and the second software program use different 
20 binary specifications. 

This object is solved by the present invention by providing a method for enabling 
a first software program using a first binary specification to employ a limited 
functionality of a second software program using a second binary specification, 
25 including the following steps: 

a) initiating the creation of a stub, which is able to transform commands relating 
to the limited functionality of the second program between the second binary 
specification and an intermediate binary specification, using a second bridge, 
wherein the second bridge provides a mapping of the second binary specifica- 
30 tion and the intermediate binary specification, 
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b) initiating the creation of a proxy, which is able to transform commands relat- 
ing to the limited functionality of the second program between the first binary 
specification and the intermediate binary specification, using a first bridge, 
wherein the first bridge provides a mapping of the first binary specification 
and the intermediate binary specification, and 

c) initiating the arrangement of the proxy and the stub relatively to the first pro- 
gram and the second program in a manner allowing the first program to em- 
ploy the limited functionality of the second program. 



According to the present invention software programs are compiled executable 
programs. Software programs are initially written in a programming language, for 
example, C++ or Java or an object model like Corba. They are compiled with 
compilers corresponding to the prograniming language. However, for each pro- 
gramming language several compilers may be available. The binary specification 
15 in which a software program is able to communicate with other software programs 
depends on both, the programming language and the compiler. This communica- 
tion language of a software program is the language referred herein as the binary 
specification used by a software program, for example, the first, the second and 
the intermediate binary specification. 



The intermediate binary specification serves as the binary specification into and 
from which the communication between the first and the second software program 
will be translated. This intermediate binary specification may be, for example, an 
existing binary specification like the binary specification of a specific compiler, 
25 but it is also possible that this intermediate binary specification is a suitable newly 
created binary specification, for example, a binary specification which facilitates 
translation into and from it 

In the scope of the present invention the two transformer modules, called proxy 
30 and stub, are created on demand, that means if and when they are needed. This 
creation on demand will be initiated directly that means by the first software pro- 
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gram or by means of an initiating function. This creation on demand is considered 
to be dynamic, so that the commands of the first software program may be dis- 
patched dynamically. The two transformer modules are at least able to transform 
commands corresponding to a limited functionality of the second software pro- 
gram. Since the first software program employs in most cases only a part of the 
functionality of the second software program, the two transformer modules need 
to transform only commands which correspond to this limited functionality. In the 
scope of the present invention commands are understood to be any kind of mes- 
sage initiating any kind of activity of a software program and which may be 
transmitted between the two software programs. 

In the scope of the present invention it is possible to insert further modules be- 
tween these two transformer modules. These modules may be able to intercept the 
commands. This interception may be used, for example, to add security or ac- 
counting functionality. It is also possible to use these two transformer modules to 
synchronize the commands or to use them for debugging. 

For the creation of the proxy and the stub mappings between the basic commands, 
on which all other commands are based, of the two pairs of participating binary 
specifications are used. These pairs are the first binary specification and the in- 
termediate binary specification and the second binary specification and the inter- 
mediate binary specification. These mappings will be provided by the bridges and 
may be, for example, stored in a data base. However, the bridges may also already 
be a part of the second software program. In case these mappings cover the com- 
plete functionality of the relevant binary specifications - which is frequently the 
case - only some parts of the mapping may be considered during the creation of 
the proxy and the stub, since they relate to the above mentioned limited function- 
ality only. 



After their creation the proxy and the stub are arranged in a manner which enables 
the first software program to communicate with the second software program. 
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That means a path of communication must be arranged from the first software 
program to the proxy, from the proxy to the stub, and finally from the stub to the 
second software program. This route must regularly be accessible from both sides, 
that means from the side of the first software program as well as from the side of 
^ 5 the second software program. 

y In order to generate the stub the second binary specification used by the second 

^ software program must be known. For this purpose, the first software program 

may start the second software program. This may be done by the first program by 
\ 10 means of a loader function which loads the second software program. Loader 

\ functions are well known in the prior art. A loader function is able to initiate a 

software program using a certain binary specification on demand of another soft- 
ware program using a different binary specification. The loader function may di- 
rectly initiate the creation of the required stub or it may initiate that the second 
15 software program or an auxiliary program communicating with the second soft- 
ware program creates the stub. This is possible, if the loader function carries or 
supplies by any means the information about the limited functionality of the sec- 
ond software program requested by the first software program. 



20 The creation of the stub may be carried out by the second software program or by 
any sub-program of the second software program. It is possible that this sub- 
program exists already in the second software program. However, this sub- 
program may as well be procured or generated by the second software program in 
response to a request of the first software. 

25 

After the creation of the stub, the initiated second software program or its sub- 
program creating the stub may inform the first software program that the stub has 
been created. This may initiate the creation of the proxy by the first software pro- 
gram or any suitable sub-program, as it was described above for the creation of 
,< 30 the stub. 



/ 



P4355DE/ARG 



The proxy is created by the first software program or a sub-program, a function 
thereof. The sub-program of the first software program must consider the bridge 
for the transformation of the first binary specification into the intermediate binary 
specification and reverse and the requested limited functionality of the second 
software program. The information about the requested limited functionality is 
generally available in the first software program, because the first software pro- 
gram requests this limited functionality from the second software program. 

In order to enable the communication between the first software program and the 
second software program the stub and the proxy may transform any commands or 
other messages between these two software programs, as far as the proxy and the 
stub support this functionality. This requires the above described arrangement of 
the proxy and the stub relatively to the first and the second software program. 

The present invention also provides a method for employing a limited functional- 
ity of a second software program using a second binary specification by a first 
software program using a first binary specification, including the following steps: 

a) initializing the limited functionality of the second software program by the 
first software program, 

b) creating a stub, which is able to transform commands relating to the limited 
functionality of the second software program between the second binary speci- 
fication and an intermediate binary specification, using a second bridge, 
wherein the second bridge provides a mapping of the second binary specifica- 
tion and the intermediate binary specification, 

c) creating a proxy, which is able to transform commands relating to the limited 
functionality of the second software program between the first binary specifi- 
cation and the intermediate binary specification, using a first bridge, wherein 
the first bridge provides a mapping of the first binary specification and the in- 
termediate binary specification, 

d) transmitting an command relating to the limited functionality from the first 
software program to the proxy, 
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e) transforming the command from the first binary specification into the inter- 
mediate binary specification by the proxy, 

f) transmitting the command transformed by the proxy from the proxy to the 
stub, 

g) transforming the transmitted command from the intermediate binary specifi- 
cation into the second binary specification by the stub, 

h) transmitting the command transformed by the stub from the stub to the second 
software program, 

i) carrying out the command in the second software program and generating a 
response for the first software program, 

j) transmitting the response, being in the second binary specification, from the 
second software program to the stub, 

k) transforming the response from the second binary specification into the inter- 
mediate binary specification by the stub, 

1) transmitting the response transformed by the stub from the stub to the proxy, 

m) transforming the response from the intermediate binary specification into the 
first binary specification by the proxy, 

n) transmitting the response transformed by the proxy from the proxy to the first 
software program. 

The transmissions between the proxy and the stub and the software programs and 
the proxy or the stub, respectively, may be effected by any suitable means. It is 
relevant, however, that these elements are arranged so as to allow the communi- 
cation of the two software programs. 

Furthermore, a method for using a stub, which is able to transform commands 
relating to a limited functionality of a second software program between a second 
binary specification and an intermediate binary specification, using a second 
bridge, wherein the second bridge provides a mapping of the second binary speci- 
fication and the intermediate binary specification, is provided for enabling a first 
software program using a first binary specification to employ the limited ftmc- 
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tionality of the second software program by further using a proxy, which is able to 
transform commands relating to the limited functionality of the second software 
program between the first binary specification and the intermediate binary specifi- 
cation, using a first bridge, wherein the first bridge provides a mapping of the first 
binary specification and the intermediate binary specification, wherein the proxy 
and the stub are arranged relatively to the first software program and the second 
software program in a manner allowing the first software program to employ the 
limited functionality of the second software program. 

Also provided is a method for using a proxy, which is able to transform com- 
mands relating to the limited functionality of the second software program be- 
tween the first binary specification and the intermediate binary specification, us- 
ing a first bridge, wherein the first bridge provides a mapping of the first binary 
specification and the intermediate binary specification, for enabling a first soft- 
ware program using a first binary specification to employ the limited functionality 
of the second software program by further using a stub, which is able to transform 
commands relating to a limited functionality of a second software program be- 
tween a second binary specification and an intermediate binary specification, us- 
ing a second bridge, wherein the second bridge provides a mapping of the second 
binary specification and the intermediate binary specification, wherein the proxy 
and the stub are arranged relatively to the first software program and the second 
software program in a manner allowing the first software program to employ the 
limited functionality of the second software program. 

In the scope of the present invention there is also provided a computer program, 
also referred to as a computer program product, for carrying out the method of the 
present invention. A computer program product comprises a medium configured 
to store or transport computer readable code, or in which computer readable code 
may be embedded. Some examples of computer program product are: CD-ROM 
disks, ROM-cards, floppy disks, magnetic tapes, computer hard drives, servers on 
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a network and carrier waves and digital signals transmitted over a telecommuni- 
cation link or network connection. 

Such computer program may be stored on any data carrier, such as, for example, a 
disk, a CD or a hard disk of a computer system. It is further provided a method for 
using a computer system, including standard computer systems, for carrying out 
the present inventive method. Finally, the present invention relates to a computer 
system comprising a storage medium on which a computer program for carrying 
out a method according to the present invention may be stored. 

The present invention can be described exemplary along the following figures, 
which shows: 

Fig. 1 : schematic representation of the inventive method in overview 
Fig. 2: flow chart: initial communication of a first and a second software 
program 

Fig. 3 : flow chart: creation of a stub 

Fig. 4: flow chart: creation of a proxy ; 

Fig. 5: flow chart: arranging a stub and a proxy 

Fig. 6: schematic representation of a computer system to be used in the 

scope of the present invention 
Fig. 7: representation of a client-server system to be used in the scope of 

the present invention 
Fig. 8 : flow chart: calling of a stub 

Fig. 9: flow chart: calling of the second program through the stub 
Fig. 10: flow chart: binding a stub and a proxy 

Fig. 1 1 : flow chart: calling the second software program from a first soft- 
ware program via a proxy and a stub 

Fig. 12: flow chart: transforming and transmitting a command from the 
first software program to the second software program 

Fig. 13: schematic representation of an interceptor arranged between a 
stub and a proxy 
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Fig. 14: flow chart: use of an interceptor function in an arrangement of 
stub and proxy 

First, reference is made to Fig. 1. A first software program 1, created with any 
convenient programming language, for example C++, and compiled with a certain 
compiler for C++, uses a first binary specification. This first binary specification 
depends on both, the programming language and on the compiler. The first soft- 
ware program 1 may be, for example, able to present numbers in graphical form. 
In order to calculate the exact dimensions of the graphs the first software program 
1 may want to employ a second software program 2, created with another pro- 
gramming language, for example Java, and compiled by using a certain compiler 
for Java. This second software program 2 uses the second binary specification for 
communication. 

The use of the second software program 2 by the first software program 1 requires 
its initialization, for example, by calling a loader function 5. The second software 
program 2 may then initialize its sub-program 2a for creating the stub 4. The sub- 
program 2a must consider the limited functionality in order to arrive at the desired 
stub 4, namely a module for transforming commands and responses relating to the 
requested limited functionality. Based on this limited functionality, the sub- 
program 2a selects the relevant mappings of the bridge 7 between the second bi- 
nary specification and the intermediate binary specification. 

The first software program 1 may correspondingly initiate a sub-program la to 
create the proxy 3 in a similar way, by employing the bridge 6 between the first 
binary specification and the intermediate binary specification. This sub-program 
la may be informed about the limited functionality from the first software pro- 
gram 1. However, it may also know this limited functionality from the second 
software program 2 by communicating via the communication channel 8. This 
30 channel 8 may be any suitable real or virtual connection which allows the transfer 
of data. 



15 



20 
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After the stub 4 and proxy 3 have been created they are arranged so as to allow the 
communication between the first software program 1 and the second software 
program 2. Once this arrangement is effected the first software program 1 sends 
the command to be transformed to the proxy 3. The proxy 3 may transform this 
command from the first binary specification into the intermediate binary specifi- 
cation. This intermediate binary specification corresponds, for example, to the 
binary UNO specification. The proxy 3 may transmit this command in the inter- 
mediate binary specification to the stub 4. The stub 4 may transform the command 
from the intermediate binary specification into the second binary specification and 
may transmit the command then to the second software program 2. 

The second software program 2 may execute the command, for example, the 
command to calculate the dimensions of a graph and may generate a response for 
the first software program 1. This response may be transformed and transmitted 
by the stub 4 and the proxy 3 from the second software program 2 to the first 
software program 1 . 

The arrows shown in Fig. 1 between the first software program 1, the proxy 3, the 
stub 4, the second software program 2 and the loader function 5 show the possible 
routes of communication. The arrows between the proxy 3 and the bridge 6 and 
between the stub 4 and the bridge 7 represent the contribution of the bridges 6 and 
7 to the creation of the proxy 3 and the stub 4, respectively. 

Fig. 2 represents an example for the initial communication of a first software pro- 
gram 1 and a second software program 2. The initial communication between the 
two software programs 1, 2 is carried out, before the creation of the stub 4 and of 
the proxy 3 is initiated. Due to the different binary specifications used by the two 
software programs 1, 2, namely the first and the second binary specification, this 
initial communication will regularly be extremely limited. It may be effected as 
explained exemplary in the following. 
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In a first step 20 the first software program 1 may call a loader function 5 for the 
second software program 2. The loader function 5 may be any known loader 
function for this second software program 2. A loader function for a program is a 
software module which "wakes up" this program so that it carries out certain 
functions. Herein, the loader function may be addressed in one binary specifica- 
tion and may wake up a program using a different binary specification. However, 
the loader function is not suited to provide any detailed communication between 
programs using different binary specifications. 



The loader function 5 may be used by the first software program 1 from the be- 
ginning. This is the case, if the first software program 1 knows or assumes that the 
second software program 2 does not use the same binary specification as itself, 
namely the first binary specification. If this knowledge is not present in the first 
15 software program 1, it may simply try to call the second software program as- 
suming that it will understand the first binary specification. In this case, the first 
software program 1 may only employ the loader function 5 if the direct communi- 
cation with the second software program 2 fails and a corresponding message is 
returned to the first software program 1 . 



In the calling step 20 the first software program 1 informs the loader function 5 
about the limited functionality requested from the second software program 2. 
Therefore, the loader function 5 must be suited to receive and carry this informa- 
tion. In order to provide this information to the loader function 5 the first software 

25 program 1 may hand over to the loader function 5 the command to be carried out 
by the second software program 2, so that the second software program 2 may, on 
receipt of the call of the loader function 5 decide itself which functionality is 
needed, or the first software program 1 may provide the loader function 5 directly 
with the description of a limited functionality of the second software program 2 

30 which will be required by the first software program 1 . 



r™ 1 — ■ 
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In step 21 the loader function 5 contacts and initializes a reception function of the 
second software program 2 to be able to transmit in the next step 22 its informa- 
tion about the limited functionality required from the second software program 2. 
In the next step 23 the second software program 2 analyses the information re- 
\ 5 ceived from the loader function 5 regarding the required limited functionality. 

After the analysis of the limited functionality required the second software pro- 
gram 2 initializes the creation of a stub 4. 

Fig. 3 shows the creation of a stub 4. The stub 4 has the task to transform com- 
10 mands sent by first software program 1 to the second software program 2 from the 
intermediate binary specification into the second binary specification used by the 
second software program 2 and to transform responses sent by the second soft- 
^ ware program 2 back to the first software program 1 from the second binary speci- 

fication into the intermediate binary specification. Furthermore, the stub 4 may be 
1 15 assigned the task to transmit the transformed commands or responses to the re- 

cipients, the second software program 2 or the proxy 3, respectively. 

In step 30 the second software program 2 may initialize a sub-program 2a for cre- 
ating the stub 4. This sub-program 2a may be an integral part of the second soft- 

20 ware program 2 or it may be as well a separate independent software module 
which can be used by this and potentially any other second software program 2. 
Accordingly, the sub-program 2a may be stored on the computer system or stor- 
age device on which the second software program 2 is stored. However, the sub- 
program 2a may also be stored on another computer system or storage device to 

25 which the second software program 2 has access. 

In step 31 the sub-program 2a receives from the second software program 2 a de- 
scription of the limited functionality required from the second software program 
2. Then, in step 32 the bridge 7 between the second binary specification used by 
30 the second software program 2 and the intermediate binary specification is con- 
tacted. This bridge 7 provides a mapping of at least all basic commands between 



13j 
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the mentioned two binary specifications. It may be stored at any place accessible 
for the sub-program 2a. In many cases there may exist a library with bridges for a 
number of second binary specifications, assuming that the intermediate binary 
specification used would be the same for all intended operations. 

From the selected bridge 7 the sub-program 2a chooses in step 33 the mappings 
necessary to use the required limited functionality of the second software program 
2. This means all transformations, but not more than these, must be selected which 
are required to transform commands and responses which could arise when using 
the relevant functionality. Finally, in step 34 the sub-program 2a creates the stub 4 
based on the chosen mappings. 

Fig. 4 represents in the form of a flow chart the creation of the proxy 3. The proxy 
3 has the task to transform commands and responses between the first binary 
specification and the intermediate binary specification. It is insofar similar to the 
stub 4 which has, as it was described above, the task to render these transforma- 
tions between the second binary specification and the intermediate binary specifi- 
cation. 

In step 40 the first software program 1 may initialize a sub-program la for creat- 
ing the proxy 3. This sub-program may be an integral part of the first software 
program 1, but may as well be separate and independent from it. The sub-program 
la may be accessible for a larger number of first software programs 1. In step 41 
the sub-program la receives from the first software program 1 information re- 
garding the limited functionality required from the second software program 2. 
This information may be provided by passing on the actual command the first 
software program 1 plans to send to the second software program 2, so that the 
sub-program la may derive from this command the information about the limited 
functionality, or the first software program 1 may provide the sub-program la 
with a description of the limited functionality. 
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In an alternative embodiment the description of the limited functionality may be 
received from the sub-program 2a for creating the stub 4. The sub-program 2a has 
the required description, because it has to create the stub 4 according to the same 
description. The description may be exchanged between the sub-program 2a and 
the sub-program la by any suitable means of communication. 

In yet an alternative embodiment the description of the limited functionality of the 
second software program 2 may be derived directly by mapping the stub 4 into the 
first binary specification, in order to create a proxy. This is possible, because the 
stub 4 reflects the required limited functionality in listings between the second 
binary specification and the intermediate binary specification which are necessary 
for the transformation of commands and responses. Therefore, the intermediate 
binary specification side of the listings of the stub 4 may be taken as the starting 
point for the creation of the proxy 3, which is completed by adding the corre- 
sponding parts of the listing in the first binary specification, as will be explained 
below. 

In step 42 the sub-program la contacts the bridge 6, which provides a mapping of 
basic commands of the first binary specification and the intermediate binary 
specification, and builds, in step 43, the desired proxy 3. 

The proxy 3 and stub 4 are then arranged to allow the desired communication 
between the first software program 1 and the second software program 2, as it will 
be described in the following along the flow chart of Fig. 5. The arrangement of 
proxy 3 and stub 4 requires that the path of exchanging transformed commands 
and responses between the proxy 3 and the stub 4 is defined. 

Therefore, in step 50 the second software program 2 informs the first software 
program 1 about the address information necessary to contact the stub 4 via the 
communication line 8. The communication line 8 may consist of a simple data 
line for transmitting binary address information which can be understood from the 
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first software program 1 without being able to use the second binary specification 
in which the second software program 2 communicates. 

The first software program 1 provides, in step 51, the sub-program la with this 
received address information, which, in step 52, is passed on to the proxy 3. The 
proxy 3 then contacts, for the first time in step 53, the stub 4, the address of which 
is now known. In step 53 the proxy 3 will also transmit its own address informa- 
tion to the stub 4, thereby allowing the stub 4 to contact the proxy 3. Herewith, the 
proxy 3 and the stub 4 are arranged for communication, that means they can send 
and receive commands and responses to commands. This arranging step is also 
referred to as binding. 

Fig. 6 shows a computer system 60 which may be used in the scope of the present 
invention. The computer system 60 comprises an i-/o-interface 61, a central proc- 
essing unit (CPU) 62 and memory 63. It is connected to an external memory 64 on 
which mass data may be stored as well as software programs. Furthermore, the 
computer system 60 is connected via the i-/o-interface 61 to an output device 65, 
for example, a screen, and to an input device 66, for example, a keyboard. 

The inventive method may be applied in the shown standard computer system. 
The first software program 1 and the second software program 2 may be stored in 
the internal memory 63 of the computer system 60, as well as on its external 
memory 64. It is also possible that one of the programs is stored on the internal 
memory 63 and the other is stored on the external memory 64. The proxy 3 and 
the stub 4 may be created by means of the CPU 62. 

The method according to the present invention may also be implemented and used 
on more than one computer system, for example, in a network or in a client-server 
system, as it is shown exemplary in Fig. 7. 
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Fig. 7 shows a client 70 which is connected to a server 71. This connection may 
be a data line 72, including any kind of permanent or temporary network, like, for 
example, the internet. It is understood that, instead of only one client, there may 
be a large number of clients connected to the server. In the scope of the present 
invention the first software program 1 may, for example, be stored on client 70, 
while the second software program 2 may be stored on server 71. The exchange of 
commands and responses may be effected via data line 72. For example, the 
bridges 6 and 7, as well as any other potentially needed bridges may be stored in 
one or more libraries on the server 71. The sub-programs la and 2a may also be 
stored on the server 71. In case the sub-program la is needed the client 70 may 
request from the server 71 its transmission via data channel 72. 

It is understood that the present invention may also be implemented in a variety of 
embodiments. In the following one embodiment of the present invention is de- 
scribed in more detail along Figures 8 to 1 1 and Tables 1 and 2. 

Creation of stub and proxy: 

In response to a call of a first software program a proxy and a stub will be created 
in the so-called proxy factory and the stub factory, respectively. In order to create 
a proxy and a stub three tasks have to be carried out. First, the first software pro- 
gram using the first binary specification has to be enabled to communicate with to 
the second software program using the second binary specification. Second, the 
stub factory has to create a uno__interface implementation considering the second 
binary specification based on the limited functionality which delivers all calls di- 
rected to the second software program to this second software program. This 
uno_interface is program code which is defined for the limited functionality. For 
the generation of the uno_interface implementation the stub factory employs in- 
formation in the form of a type description. This uno_interface implementation is 
also referred to as the stub. Third, the proxy factory has to create a uno_interface 
implementation for the first binary specification. The proxy factory generates its 
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unojnterface implementation based on the information of the type description. 
This uno_interface implementation is referred to as the proxy. 



The knowledge of the type description is necessary to create the stub and the 
proxy, as described. This type description is the full description of the limited 
functionality, also called interface. It contains the information about the required 
limited functionality of the second software program which shall be used by the 
first software program. The type description may refer to different types shown in 
Table 1. 



Table 1: 



[Type 



iByte 
tehort 



\UNO 



jSigned 8 Bit 



[C++ 



lUshort 



tSigned 16 Bit 



[Signed 8 Bit 



\Java 



[Long 
' lUtong 



[Unsigned 16 Bit 
ISigned 32 Bit 
jUn 



tSigned 16 Bit 



[Signed 8 Bit 



Unsigned 32 Bit 



lUnsigned 16 Bit 
^[Signed 32 Bit 



ISigned 16 Bit 



" ^Signed 16 Bit 



Hyper jSigned 64 Bit 



[Unsigned 32 Bit 



{Signed 32 Bit 



Uhyper [Unsigned 64 Bit 



Float 



{'rocessor dependent: Intel, Sparc = 
EEE float 



" jSigned 64 Bit 
[Unsigned 64 Bit 



[Signed 32 Bit 
^[Signed 64 Bit 



Double 



Processor dependent Intel, Sparc = 
[IEEE double 



[Processor dependent Intel, Sparc = 
[float 



IEEE 



[Signed 64 Bit 



Enum 



Boolean 



E'rocessor dependent: Intel, Sparc = 
ouble 



IEEE float 



IEEE 



IEEE doubte 



he size of an machine word. Normally 
his is the size of an integer. 



1 Byte. 



t [The sizi 
pis is tl 

1l Byte. 



ie size of an machine word. Normally 
is is the size of an integer. 



All enum values of one enum declaration 
are static object of a class. Each object 
contains a 32 bit value which represents 
the enumeration vafue. 



Boolean 



Char 



16 Bit on WNT, W95, W98, Os2. 32 Bit 
on Unix 



String 



Structure 



Union 



A pointer to a structure which have the 
following members: 
long refCount; 
long length; 
wchar_t bufferf...]; 
The string in buffer is 0 terminated. 
This is the rtt_wString structure in the 
rtl-library 



The structure contains the members in 
the order of the declaration. The 
memory layout is descnbed at the 
beginning of this chapter. 



Sequence 



1 6 Bit on WNT, W95, W98, Os2. 32 Bit on 
Unix 



Unsigned 16 bit (char) 



A pointer to a structure which have the 
following members: 
long refCount; 
long length; 
wchar_t buffer*...]; 

The string in buffer is 0 terminated. This is 
the rtLwString structure in the rtl-library 



java.lang.String - 



The size is 4 + size of the largest type. 
In front of the union members are a 
long value (nSelect) which describes 
the position of the valid member (0 is 
the first). 



The structure contains the members in the 
order of the declaration. The memory 
layout is described at the beginning of this 
chapter. 



The size is 4 + size of the largest type. In 
front of the union members are a long 
value (nSelect) which describe the posi- 
tion of the valid member (0 is the first). 



pointer to a structure which has the 
following members: 
void * p Elements; 
long nElements; 
long nRefCount; 

The pElements are a memory area that 
contains nElements elements. 



Exception Looks like a structure 



A class which is derived from 
javaJang.Objecr and contains the mem- 
bers in the specified order. 



Not specified yet 



A pointer to a structure which has the 
following members: 
void * pElements; 
long nElements, 
long nRefCount; 

The pElements are a memory area that 
contains nElements elements. 



It is a normal Java array. 



Looks like a structure 



Interface 



Eie interface is a pointer to a function St is a pointer to a C++-Class which im- 
b[r . . 



_|ttt 



ble, which contains 3 functions. b'ements first the virtual methods query- \ lt is a normal Java interface. 



class which is derived from 
iava.lang. Exception" and contains the 
lembers in the specified order. 
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Type 


\UNO 


1C ++ 


Uava 




\ 


(Interface, acquire and release. 


1 


Any 


[This is a structure that contains a 
pointer to a type description. The 
second member is a pointer to the 
talue stored in the any. 


[This is a structure that contains a pointer 
to a type description. The second member 
is a pointer to the value stored in the any. 


|A class which is derived from 
Ljava.lang. Object". The members are a 
class, which descnbe the type of the value. 
VK second member which is the value of the 


Void 


]No memory representation 


JNo memory representation 


JNo memory representation 



Many of these types are self-explaining and known in the art. Nevertheless, the 
most relevant types of the type description will be explained in more detail below. 

"Interfaces": All interfaces employed in connection with the present embodiment 
are derived from a Super-Interface. Each interface contains at least three methods. 
The two methods "acquire" and "release" are necessary to control the lifetime of 
the interface. The third method "querylnterface" is used to navigate between dif- 
ferent Interfaces. A XInterface includes only these three methods. All other inter- 
faces are derived from this XInterface. The methods and functionalities requested 
by the first software program will be part of the interface. 

In Java, for example, interfaces are mapped to Java interfaces which could be 
normally implemented. The methods acquire and release are not mapped to the 
Java program since this methods do not exist in Java. The lifetime of the proxy, 
the stub and the relevant information in the second program will be controlled by 
a garbage collector. The programming language Java delivers basic types by value 
and non-basic types by reference. All calls are specified by value except inter- 
faces. So in Java all non-basic types returned or delivered through out parameters 
are by value, which means that the implementation must copy it before return or 
deliver. 

In C++, for example, interfaces are mapped to pure virtual classes. In order to 
automatically control the lifetime of interfaces a template called "Reference" will 
be used. All return, parameter and member types are "References" (e.g.: Refer- 
ence< XInterface >). The "Reference" acquires the interface when it is con- 
structed and releases the interface when it is destructed. 
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"Structure": A structure is a collection of elements. The type of each element is 
fixed and it cannot be changed. The number of elements is fixed. 

"Exceptions": An exception is a program control construct beside the normal 7 
control flow. One major feature of exceptions is, that it is simpler to implement 
the error handling. Exceptions are similar to structures since they are also a col- 
lection of elements and each type of each element is fixed and cannot be changed \ 
and the number of elements is also fixed. An additional feature of exceptions is ' 
that they can be thrown by a method. All exceptions which can be thrown by a 
method must be declared at the method, except for the called "RuntimeException" 
which always can occur. All exceptions must be derived from "Exception". If an 
exception is declared at a method it is allowed to throw all derived exceptions. 
The caller of a method must respond to this behavior. 

In Java, for example, all exceptions are derived from the "java.Iang.Exception". 
The exceptions are declared at the methods. 

In C++, for example, the exceptions are generated as structures. An exception is 
thrown as instance (e.g.: throw RuntimeExceptionO). At the other side the excep- 
tion should be caught as reference (...catch(RuntimeException &){... }). 

"Union": A union contains one element. The declaration of a union specifies the 
possible types. 

"Array": An array contains any number of elements. The type of the elements is 
fixed and cannot be changed. 

"Any": An any contains one element. All types of elements are possible. An any 

contains a reference to the value and the type description of the type. With the x 

type description the bridge can transform the value, if necessary. 
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In Java the any is, for example, represented by the class "Any", which contains a 
class as type description and a "java.lang.Object", which is the value. The basic 
types are wrapped to their proper classes. For example, a boolean value is an ob- 
ject of the class "java.lang.Boolean", which contains the value. 

In C++ the any is represented through the class "Any". Each type generated by a 
C++ codemaker implements an function "getCppuType". This function is used to 
implement the template access operators "«=" and "»=". These operators insert 
and extract the value of the any* 

"Sequence": A sequence is a generic data type. It contains the number of elements 
and the elements. In Java the specification of an array fulfills this specification. 
This is not true for C++. The array in C++ does not contain the number of ele- 
ments* It is not possible to return a C++-array, e.g. Char[] getNameO is not possi- 
ble. It is difficult to manage the lifetime between the called and the caller, if only 
a pointer is returned. Therefore, in C++ a sequence is a template with the name 
"Sequence". The implementation contains a pointer to a structure which contains 
a pointer to the elements, the number of elements and the reference count. So it 
holds the binary specification. It is cheap to copy this sequence, because only the 
reference count is incremented. 

The type description may exist or it may be runtime created. Each existing type is 
stored in a type repository along with the corresponding type description. The 
types of the type description are accessible through the full name of each type in 
the type repository. For example, the full name of the type "Xinterface" may be 
"com.sun.star.Xinterface". 

In a type repository the types needed for any type description are stored in any 
appropriate way. If the API (application program interface) of the type repository 
is c-style, it is directly, that means via a binary representation, accessible from 
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many binary specifications and it is quickly transferable. Since the type descrip- 
tion of each element may be used during the generic marshaling of a call, the ac- 
cess performance of the type repository API is critical. Therefore, it is useful to 
use c-style structures, which describe each type. In addition, there may be inter- 
faces declared which specify the access to the type repository. The module of this 
interface is "com. sun. star. typelib". 

All functions or type declarations have the prefix "typelib_". All elements are 
reference counted. All elements start with the structure "type- 
lib_TypeDescription". It is possible to cast all descriptions to this type. The func- 
tion typelib_typedescription_newInterface will be used to create an interface de- 
scription. The descriptions of structures, unions and sequences are created with 
the function typelib_typedescription_new. The description of the base type is ini- 
tially part of the type repository. The function to get a type description is 
typelib_typedescription_getByName. 

The Java API to the type repository is different for two reasons. First, Java cannot 
access the binary representation of the type descriptions directly. Second, the Java 
runtime system provides an API (core reflection) similar to the type repository 
API. Unfortunately, the features "unsigned", "oneway" and "out parameters" are 
missing in this API. For this reason, additional information is written into the 
classes. 

The representation of the types depends on the hardware, the language and the 
operating system. The base type is swapped, for example, if the processor has 
little or big endian format. The size of the types may vary depending on the proc- 
essor bus size. The alignment is processor and bus dependent. The alignment of 
the data structure is defined through the following algorithm: 

Structure members are stored sequentially in the order in 
which they are declared. Every data object has an alignment- 
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requirement. For structures, the requirement is the largest of its 
members. Every object is allocated an offset so that offset % 
alignment-requirement = 0 

If it is possible that the maximum alignment can be restricted (Microsoft C/C++ 
compiler, IBM C/C++ compiler) than the size maximum alignment is set to eight. 
Under this condition the alignment is set to min( n, sizeof( item ) ). The size is 
round up to the largest integral base type. 

For the Microsoft and IBM C/C++ compiler the alignment of structure is set to 
eight using the "#pragma" statement. Table 1 shows the binary UNO, C++ and the 
Java types. 

In order to address the proxy factory to generate the proxy the first binary specifi- 
cation has to be denominated. This will be a string, because it is extensible and the 
risk of double names is low. Then a tool for selecting the desired bridge is called. 
The first parameter for this tool is the "first binary specification" and the second 
parameter is the intermediate binary specification "UNO". Then a function is 
called for selecting the desired mapping of the bridge. The name of the function 
is, in this example, "getMappingFactory". A call to create a proxy in "objective c" 
will be "getMappingFactory("objective_c", "uno")" The implementation of the 
function will search a shared library named "objective_cuno" to find the right 
library that contains the proxy factory. In Java the tool may search for a class of 
name "objective_cuno". 

In order to create a stub merely the parameters of the function have to be changed, 
in our example to "getMappingFactory("uno", "objective_c")'\ A stub imple- 
ments the uno_interface. In the dispatch function the stub must call the right 
method of the original object. This is simpler in a programming language like 
Java, which has a "core reflection API", than in a programming language like 
C++, which has no binary standard and no API to call virtual methods. 
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In creating a proxy the proxy factory must generate method code to implement 
each method specified in the interface to be created. The only information to do 
this is a type description of the interface. For example: In Java (1.1) a binary class 
file (* .class) must be generated and loaded with the class loader. In the absence of 
a loader which can directly load binary classes a loader has to be provided. In C++ 
virtual method tables must be generated which delegate each call to the 
unojnterface. In the absence of a binary C++ specification individual compilers 
(version, switch,...) may have to be explored in order to implement this. 

The proxy and the stub factory employ bridges for the generation of the proxy and 
the stub, respectively. A bridge implements infrastructure to exchange interfaces 
between two environments and is bidirectional. 

An environment contains all objects which suffices the same specification and lies 
in the same process address space. The environment is specific for a programming 
language and for a compiler. For example, an object resides in the "msci" envi- 
ronment, if it is implemented in C++ and compiled with the Microsoft Visual C++ 
compiler. It may also be session specific for some reason, e.g. when running mul- 
tiple Java virtual machines in one process. In the latter case these virtual machines 
have to be distinguished. However, this case is not a common case. 

Regularly, the environment is the area in which the same binary specification is 
employed. Therefore, the first software program and the second software program 
belong to different environments. 

Each bridge is implemented in a separate shared library. The name of the library is 
a connection of two environment names with an underscore ('J) between the 
names. Each bridge library exports two functions called <& uno_ext__getMapping" 
and "uno_initEnvironmenf \ The first function is called to get the mappings. 
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In order to get a mapping uno_getMapping() has to be called. There is also a C++ 
class called cppu_Bridge which can be used with the source and destination envi- 
ronment names. The uno_ext _getMapping() call then receives its source and des- 
tination environments. The bridge library cannot be unloaded while any code of it 
5 is still needed. So both mappings and any wrapped interface (proxy) that is ex- 
ported needs to modify a shared library wide reference count. If the shared library 
can be unloaded the reference count goes to zero. 

The intention of an environment structure is to provide common functions like 
10 acquirelnterfaceO and to know all proxy interfaces and their origins. This is spe- 
cifically important because of the object identity of an interface. The proxy, the 
stub and the second program are defined to provide the same instance of the XTn- 
terface any time it is queried for it. This is important to test, if two interfaces be- 
long to the same object (e.g. testing the source of an incoming event). 

15 

When interfaces are mapped around some environments in space, they must pro- 
vide the same XInterface in each environment (e.g. in C-Hh, equal XInterface 
pointers). 

20 It is not recommended to only keep an eye on this object identity issue. It is well 
recommended to reuse any interface, i.e. rejecting the production of proxy inter- 
faces as often as possible, because each constructed proxy interface leads to an- 
other indirection when called, and there will of course be many interfaces. 

25 So an environment knows each wrapped interface (proxy) running in it and the 
origin of each of these interfaces. Table 2 shows the representation of an envi- 
ronment. 



Table 2: 

30 struct uno_Environment 
{ 

/** 

* a name for this environment 
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*/ 

rtl_String * pName; 
/** 

* a free context pointer, that can be used for specific classes of envi- 
ronments, 

* e.g. a jvm pointer 
*/ 

void * pContext; 
/** 

* Acquires this environment. 
*<BR> 

* Qparam pAccess this access interface 
*/ 

void (SAL CALL * acquire) ( uno Environment * oEnv ) ; 
/** 

* Releases this environment; 

* last release of environment will revoke the environment from runtime 
*<BR> 

* @param pAccess this access interface 
*/ 

void (SAL_CALL * release) { uno_Environment * pEnv ) 
/** 

* Tests if two environments are equal. 
*<BR> 

* @param pEnvl one environment 

* @param pEnv2 another environment 
*/ 

sal_Bool ( S AL_CALL * equals) ( const unoJEnvironment * pEnvl, 

const uno_Environment * pEnv2 ) ; 

/** 

* You register internal and external interfaces via this method. 

* Internal interfaces are proxies that are used in an environment. 

* External interfaces are interfaces that are exported to another 

* environment, thus providing an object identifier for this task. 

* This can be called an external reference. 

* Interfaces are held weakly at an environment; they demand a final 

* revokelnterfaceOcall for each interface that has been registered 
*<BR> 

* Qparam pEnv this environment 

* @param pplnterface inout parameter for the registered interface 

* @param ppOId inout parameter for the corresponding object id 

* @param pTypeDescr type description of interface 

* @param acquire function to acquire an interface; 

* this function provides a boolean return 

* value to signal if the acquisition was successful (necessary for 

* proxy interfaces) 
*/ 

void (SAL_CALL * registerlnterface) ( uno_Environment * pEnv, 

void ** pplnterface, 
rtljString ** ppOId, 

typelib_InterfaceTypeDescription * 

pTypeDescr, 

uno_regAcquireFunc acquire ); 

* You have to revoke ANY interface that has been registered via this 



method. 



*<BR> 

* @param pEnv this environment 

* Oparam pOId object id of interface to be revoked 

* Qparam pTypeDescr type description of interface to be revoked 

* y 

void <SAL_CALL * revokelnterf ace ) ( uno_Environment * pEnv, 

rtl_String * pOId, 

typelib_InterfaceTypeDescription * pTypeDescr ), 

/** 

* Retrieves an interface identified by its object id and type from 

* this environment. 





,DESC ' ; 
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was found 



before 



*<BR> 

* @param pEnv this environment 

* @param pplnterface inout parameter for the registered interface; 

* (0) if none was found 

* @param pOId object id of interface to be retrieved 

* @param pTypeDescr type description of interface to be retrieved 
*/ 

void <SAL_CALL * getRegisteredlnterf ace) { uno_Environment * pEnv, 

void ** pplnterface, 
rtl_String * pold 7 

typelib_InterfaceTypeDescription * 

pTypeDescr ) ; 

/* * 

* Retrieves the object identifier for a registered interface from 

* this environment* 
*<BR> 

* ©param pEnv this environment 

* Qparam ppOId inout parameter for object id of interface; (0) if none 

* Oparam plnterface a registered interface 

* Gparam pTypeDescr type description of interface 
*/ 

void (SAL_CALL * getRegisteredObj ectldentif ier ) ( uno_Environment * pEnv, 

rtl_String ** ppOId, 
void * plnterface, 

typelib_InterfaceTypeDescription * 

pTypeDescr ) ; 

/** 

* Disposing callback function pointer that can be set to get signalled 

* the environment is destroyed. 
*<BR> 

* @param pEnv environment that is being disposed 
*/ 

void (SAL_CALL * envirorunentDisposing) ( uno_Environment * pEnv ); 
/** 

* Computes an object identifier for the given interface; is called by 

* the environment implementation. 

* <BR> 

* Qparam pEnv corresponding environment 

* @param ppOId out param: computed id 

* @param plnterface an interface 
*/ 

void (SAL_CALL * computeObj ectldentif ier) ( uno_Environment * pEnv, 

rtl_String ** ppOId, void * plnterface ) ; 

/** 

* Function to acquire an interface. 
*<BR> 

* @param pEnv corresponding environment 

* eparam plnterface an interface 
*/ 

void (SAL_ CALL * acquirelnterf ace) ( uno_Environment * pEnv, void * plnter- 

* Function to release an interface. 
*<BR> 

* @param pEnv corresponding environment 

* @param plnterface an interface 
*/ 

void ( SAL_CALL * release Inter face) ( uno__Environment * pEnv, void * plnter- 



face ) j 



face ) , 
}; 
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Environments, as defined above, consist of several fields. The first fields are used 
for identifying the environment, for specifying the hardware, the process, and 
maybe a session specific ID. There is also a context pointer which can be used for 
specific classes of environments, e.g. when it is known that there is a Java envi- 
5 ronment the virtual machine pointer can be stored there. / 

/ 

In order to use environments, these environments regularly have to be registered. / 
An existing environment may be obtained by calling uno_getEnvironment(). A j 
new environment can be created by either implementing it directly or by using a 
10 simple default implementation, which is frequently also sufficient, by calling, in 
the given example, uno_createDefaultEnvironment() with the environment's name 
and its acquire and release function for interfaces. 

In order to improve the performance the bridges should use the shortest way be- ^ 
15 tween two environments. Especially, if there are programs instantiated in the 
identical environment, the communication between them should be direct and not 
over a proxy and a stub. 



Mapping is the direct way to publish an interface in another environment. That 
20 means an interface is mapped from a source environment to a target environment 
so that methods may be invoked on a mapped interface in the target environment 
which are delegated to the originating interface in the source environment. A 
mapped interface may also be called a proxy or a stub. Mapping an interface from 
an environment A to an environment B requires that several steps are performed: 
25 First, the origin of the interface from environment A has to be retrieved (call 
getlnterfaceOriginO on environment A). For this purpose, the environment A 
looks into its proxy interfaces table to check if there is such an interface already 
known (pointer and type). If the answer is no, then this interface must originally 
come from environment A, or else it must originate from any other environment 
30 and its origin must be known, since each proxy interface must have been regis- 
tered with its origin. Second, an existing proxy interface has to be looked for in 
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environment B with the same origin and type (call getlnterface() on environment 
B). If a proxy interface of that origin and type is already in use in environment B, 
then this interface is acquired, or else a new proxy has to be constructed wrapping 
the source interface from environment A. The fresh proxy interface is then to be 
5 registered via registerlnterface() on its first acquireO and revoked via revokelnter- 
faceO on its last release() from its environment. This second step has to be syn- 
chronized with other threads in order to get access to mapping tables of an envi- 
ronment by getting an access interface (lockAccessO) from the environment. Then 
an unlockAccessO function has to be called. 

10 

Function of stub and proxy: 

The stub is encapsulated in an object which delivers and transforms the binary 
specification adapted calls to the stub. This object is the proxy of a stub in the first 
15 binary specification. This proxy which calls and attributes access will be similar 
with the binary specification from which the call was made. The calling to the 
stub is shown in Fig. 8. 

First in step 81 a type save call (e.g. acquire, querylnterface, ...) is made at the 
20 proxy 3. This type save call will be transformed by the proxy 3 to a corresponding 
call in step 82 and dispatched to the stub 4 in step 83. After that, the return value 
of this call is transformed in step 84 to the type expected by the binary specifica- 
tion. 

25 The proxy is binary specification specific. So it is possible to put this object 
seamless into the binary specification. 

A stub object is also created which implements an uno_interface and transforms 
and delegates the calls to the second program implemented in a specific pro- 
30 gramming language (e.g. C++, Java,...). Fig. 9 describes a call through a stub 4 to 
the second program 2. 
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In a first step 91 the dispatch function is called. If proxy and stub are running in 
the same process, the dispatch function of the stub is directly called by the proxy. 
In a distributed environment this is not possible. In this case the abstract virtual 
5 channel has to provide this functionality. On the proxy side the proxy will accept 

the request and transmit it to the stub side. On the stub side the stub has to call the ) 
dispatch function. 

The stub 4 detects the interface and the method which should be called at the sec- / 
10 ond program 2. Then in step 92 the call was transformed into a specific binary , 
specification by the stub 4 and the second program 2 was called in step 93. After 
that, the return value was re-transformed to the other binary specification in step 
94. 

/ 

15 The stub makes all transformations to the binary specification in which the second 
program is implemented. This is in this example the second binary specification. 
This makes it possible to implement the second program in the second binary 
specification. For example: In C++ exceptions, multiple inheritance and deriva- 
tion can be used. In addition to the binary specification there are the type descrip- 

20 tions which must be mapped in the binary specification of the second program. 

In order to enable to call from one binary specification or object model to another 
the stub and the proxy have to undergo a binding process. The proxy allows to call 
from one binary specification to the uno__interface, while the stub allows to call 
25 through the unojuriterface to the second program. The binding of the stub and the 
proxy is initiated by the first software program 1 and is shown in Fig. 10. In a first 
step 101 the generation of a stub with the binary UNO specification in the stub 
factory 102 is shown. In a second step 103 a proxy is created based on the gener- 
ated stub in the proxy factory 104. 

30 
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Each call to the proxy is delivered to the stub. The stub prepares the call and calls 
the second program in the corresponding binary specification. Fig. 1 1 shows ex- 
emplary the call from a first software program 1 in a programming language like 
"objective c" to a second software program 2 which may be implemented in the 
5 programming language C++. 

The first software program 1 uses the programming language "objective c'\ The 
proxy 3 makes the interface available to the first software program 1 in the first 
binary specification. This means the first software program 1 uses the first binary 

10 specification to manipulate the second software program 2. For example, this may 
be effected by the call „char * pOldText = [ myObject changeText: "test"]" in step 
111. The proxy 3 transforms the parameter of type string to the binary specifica- 
tion in step 1 12. Then, the proxy 3 dispatches in step 113 the call to the stub 4. 
The necessary information, including a method type description, parameters, an 

15 address for the return value and an address for the exception, if any occurs, is de- 
livered to the stub 4. The stub 4 transforms in step 114 the string from the binary 
UNO specification to a second binary specification string. The stub 4 calls the 
right method at the second software program 2 in step 115, in our example 
"pComponent->changeText("test")'\ The stub 4 must catch all kind of exceptions 

20 thrown by the second software program 2. If the method returns normally, the 
string is transformed in the step 1 16 to the binary UNO specification and stored at 
the place given through the dispatch call. If an exception is thrown, the exception 
is transformed and stored at the address given through the dispatch call. After the 
dispatch call returns the proxy 3 transforms in step 117 the string to a first binary 

25 specification string and returns from the "changeText" call. If the call terminates 
by an exception, the exception is returned to the first software program 1 . It is up 
to the first binary specification in which manner the exception occurs (the "objec- 
tive c" language does not support exception handling). 

30 Fig. 12 shows the advantage of the binary UNO specification as an intermediate 
binary specification as it was described above. In a first step 121 the first software 
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program 1, for example written in the programming language C++, transmits one 
command in a first binary specification, in this example the command "setText("a 
test")", to the proxy 3. Regularly, the first software program will transmit more 
than one command, for example, also the acquire, the release and the queryfriter- 
5 face command as described above. This command will be transformed by the 
proxy 3 in the next step 122 from the first binary specification into the binary 
UNO specification. The command in the binary UNO specification contains the 
following information: the parameter "a test", the return address, an address for 
the exceptions, and the type description of the command "setText". The type de- 

10 scription of this command will include, in this example, the name of the command 
(setText), the type of the parameter and the return type. This transformed com- 
mand will be transmitted to the stub 4 in the step 123. Then, the stub 4 transforms 
in step 124 the command from the binary UNO specification into the second bi- 
nary specification, employed by the second software program 2 which was writ- 

15 ten, for example, in the programming language Java. The stub 4 employs for this 
transforming step only one dispatch mechanism. This is a mechanism which will 
be employed for each command transmitted by the proxy 3, since it is able to dis- 
patch the name of the command and the other relevant information to the second 
software program 2. In the final step 125 the second software program 2 executes 

20 the command "setText". The response to this command will be transmitted and 
transformed in a corresponding way. 



Fig. 13 shows a scenario where between the proxy 3 and the stub 4 an interceptor 
130 is inserted. This means, that the stub 4 and the interceptor 130 are created in a 
25 first step, while in a second step the stub 3 is created based on information about 
the stub 4 and the interceptor 130. Therefore, the proxy 3 will communicate only 
with the interceptor 130 and not with the stub 4. 



30 



Such an interceptor may be able to carry out, for example, an accounting function 
or a security check function. If, for example, the first software program 1 wants to 
use a functionality of the second software program 2, the interceptor may be able 
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to discover if the user of the first software program is authorized to use this func- 
tion and to debit the account of the user, if the user has to pay for this functional- 
ity. Such an interceptor may also be used, for example, to help debugging the 
communication between a first software program 1 and a second software pro- 
5 gram 2. In such a case the interceptor may provide an alarm function which will 
be initiated, if a predefined functionality is called. If the functions requested from 
the second software program 2 may be grouped as one transaction, it may also be 
possible that an interceptor cancels all already executed functions of this group, if 
one function fails. Such an interceptor has the advantage that only one interceptor 
10 may be employed for every function or method of an interface and for all binary 
specifications of software programs which communicate via the intermediate bi- 
nary specification used by the stub 4 and the proxy 3. 

Fig. 14 shows a flow chart representing the use of an interceptor as checking and 
15 accounting function for a fax service. In this example, a user of a first software 
program using a first binary specification wants to use the fax service of a second 
software program using a second binary language. This fax service may distin- 
guish between two kinds of users. A standard user may have to pay for each fax 
and a premium user may have to pay a monthly standard fee. 

20 

In order to enable the communication between the two software programs a stub 
and a proxy , will be created and combined and arranged together with a specific 
interceptor in a way shown in Fig. 13. Then, the following steps may be carried 
out in using the invention. 

25 

In step 140 the first software program sends a command including the desired fax 
number, the corresponding fax file and the identity of the user to the proxy. The 
proxy transforms this command into the intermediate binary specification and 
forwards it to the interceptor in step 141. The interceptor checks in step 142 
30 whether the user is a standard user. 
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If the answer is "Yes", that means the user is a standard user, the interceptor may 
deteremine in step 143 whether the user has enough credit. If the answer to this 
question is "No", the user will be informed about his insufficient credit status and 
about the fact that the fax was yet not sent in step 144. If the answer is "Yes", that 
5 means that the user has enough credit, the interceptor will initiate, in this example, 
the debiting of the user's account in step 145 and forward the received command 
to the stub in step 146. 

If the answer in step 142 is <e No", that means the user is a premium user, the inter- 
10 ceptor will forward the command received from the proxy directly to the stub in 
step 146. The stub will transform this command from the intermediate binary 
specification into the second binary specification and forward this command to 
the second software program in step 147. Then the fax may be sent. 



15 It will be understood that the present invention is not limited to the examples gi- 
ven and explained in detail. 
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Claims 



1. A method for enabling a first software program using a first binary specifica- 
tion to employ a limited functionality of a second software program using a 
second binary specification, including the following steps: 

a) initiating the creation of a stub, which is able to transform commands re- 
lating to said limited functionality of said second software program be- 
tween said second binary specification and an intermediate binary specifi- 
cation, using a second bridge, wherein said second bridge provides a map- 
ping of said second binary specification and said intermediate binary 
specification, 

b) initiating the creation of a proxy, which is able to transform commands 
relating to said limited functionality of said second software program be- 
tween said first binary specification and said intermediate binary specifi- 
cation, using a first bridge, wherein said first bridge provides a mapping of 
said first binary specification and said intermediate binary specification, 
and 

c) initiating the arrangement of said proxy and said stub relatively to said 
first software program and said second software program in a manner al- 
lowing said first software program to employ said limited functionality of 
said second software program. 

A method for employing a limited functionality of a second software program 
using a second binary specification by a first software program using a first 
binary specification, including the following steps: 

a) initializing said limited functionality of said second software program by 
said first software program, ; 
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b) creating a stub, which is able to transform commands relating to said lim- 
ited functionality of said second software program between said second 
binary specification and an intermediate binary specification, using a sec- 
ond bridge, wherein said second bridge provides a mapping of said second 

5 binary specification and said intermediate binary specification, 

c) creating a proxy, which is able to transform commands relating to said 
limited functionality of said second software program between said first 
binary specification and said intermediate binary specification, using a 
first bridge, wherein said first bridge provides a mapping of said first bi- 

10 nary specification and said intermediate binary specification, 

d) transmitting an command relating to said limited functionality from said 
first software program to said proxy, 

e) transforming said command from said first binary specification into said 
intermediate binary specification by said proxy, 

f) transmitting said command transformed by said proxy from said proxy to 
said stub, 

g) transforming said transmitted command from said intermediate binary 
specification into said second binary specification by said stub, 

h) transmitting said command transformed by said stub from said stub to said 
20 second software program, 

i) carrying out said command in said second software program and generat- 
ing a response for said first software program, 

j) transmitting said response, being in said second binary specification, from 

said second software program to said stub, 
k) transforming said response from said second binary specification into said 

intermediate binary specification by said stub, 
1) transmitting said response transformed by said stub from said stub to said 
proxy, 

m) transforming said response from said intermediate binary specification into 
30 said first binary specification by said proxy, 
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n) transmitting said response transformed by said proxy from said proxy to 
said first software program. 

3. A method for using a stub, which is able to transform commands relating to a 
limited functionality of a second software program between a second binary 
specification and an intermediate binary specification, using a second bridge, 
wherein said second bridge provides a mapping of said second binary specifi- 
cation and said intermediate binary specification, for enabling a first software 
program using a first binary specification to employ said limited functionality 
of said second software program by further using a proxy, which is able to 
transform commands relating to said limited functionality of said second soft- 
ware program between said first binary specification and said intermediate bi- 
nary specification, using a first bridge, wherein said first bridge provides a 
mapping of said first binary specification and said intermediate binary specifi- 
cation, wherein said proxy and said stub are arranged relatively to said first 
software program and said second software program in a manner allowing 
said first software program to employ said limited functionality of said second 
software program. 

4. A method for using a proxy, which is able to transform commands relating to 
said limited functionality of said second software program between said first 
binary specification and said intermediate binary specification, using a first 
bridge, wherein said first bridge provides a mapping of said first binary speci- 
fication and said intermediate binary specification, for enabling a first soft- 
ware program using a first binary specification to employ said limited func- 
tionality of said second software program by further using a stub, which is 
able to transform commands relating to a limited functionality of a second 
software program between a second binary specification and an intermediate 
binary specification, using a second bridge, wherein said second bridge pro- 
vides a mapping of said second binary specification and said intermediate bi- 
nary specification, wherein said proxy and said stub are arranged relatively to 
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said first software program and said second software program in a manner al- 
lowing said first software program to employ said limited functionality of said 

second software program. 

5 5. A method according to any of the preceding claims, wherein said creation of 
said stub is carried out in response to a loader function for said second soft- 
ware program. 
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6. A method according to any of the preceding claims, wherein said creation of 
said proxy is carried out in response to a function of said first software pro- 
gram. 

7. A method according to any of the preceding claims, wherein said creation of 
said stub is carried out by a sub-program of the second software program. 

8. A method according to any of the preceding claims, wherein said creation of 
said proxy is carried out by a sub-program of the first software program. 

9. A method according to any of the preceding claims, wherein said bridges are 
20 selected by a tool for selecting the desired bridge. 

10. A method according to any of the preceding claims, wherein said mappings 
are selected by a function for selecting the desired mapping of the bridge. 

25 11. A method according to any of the preceding claims, wherein said limited 
functionality is described by types. 

12. A method according to claim 11, wherein the types are stored in a type re- 
pository. 

30 
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13. A method according to claim 12, wherein the types are stored in said type re- 
pository along with the corresponding description. 

14. A method according to claim 12 or 13, wherein a application program inter- 
face of said type repository is c-style. 

15. A method according to any of the preceding claims, wherein said first binary 
specification and said second binary specification are denominated by a string. 

10 16. A method according to any of the preceding claims, wherein an interceptor is 
arranged between said proxy and said stub in order to intercept some of said 
commands. 

17. A method according to any of the preceding claims, wherein said stub is able 
15 to transform all commands transmitted by the proxy by employing one dis- 
patch mechanism. 

18. A computer program for carrying out a method according to any of the pre- 
ceding method claims on a computer system. 

20 

19. A data carrier for storing a computer program for carrying out a method ac- 
cording to any of the preceding method claims on a computer system. 

20. A method for using a computer system for carrying out a method according to 
25 any of the preceding method claims. 



21. A computer system comprising a storage medium on which a computer pro- 
gram for carrying out a method according to any method claim is stored. 
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Abstract 



A method for enabling a first software program using a first binary specification 
to employ a limited functionality of a second software program using a second 
binary specification, including the following steps: 

a) initiating the creation of a stub, which is able to transform commands re- 
lating to said limited functionality of said second software program be- 
tween said second binary specification and an intermediate binary specifi- 
cation, using a second bridge, wherein said second bridge provides a map- 
ping of said second binary specification and said intermediate binary 
specification, 

b) initiating the creation of a proxy, which is able to transform commands 
relating to said limited functionality of said second software program be- 
tween said first binary specification and said intermediate binary specifi- 
cation, using a first bridge, wherein said first bridge provides a mapping of 
said first binary specification and said intermediate binary specification, 
and 

c) initiating the arrangement of said proxy and said stub relatively to said 
first software program and said second software program in a manner al- 
lowing said first software program to employ said limited functionality of 
said second software program. 
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